From: Andrew Cooper Date: Tue, 20 Jan 2015 09:42:26 +0000 (+0100) Subject: xsm/evtchn: never pretend to have successfully created a Xen event channel X-Git-Tag: archive/raspbian/4.8.0-1+rpi1~1^2~3899 X-Git-Url: https://dgit.raspbian.org/%22http:/www.example.com/cgi/%22https:/%22bookmarks://%22/%22http:/www.example.com/cgi/%22https:/%22bookmarks:/%22?a=commitdiff_plain;h=09aa4759faa29c1fe735266de4c79f17329bd67b;p=xen.git xsm/evtchn: never pretend to have successfully created a Xen event channel Xen event channels are not internal resources. They still have one end in a domain, and are created at the request of privileged domains. This logic which "successfully" creates a Xen event channel opens up undesirable failure cases with ill-specified XSM policies. If a domain is permitted to create ioreq servers or memevent listeners, but not to create event channels, the ioreq/memevent creation will succeed but attempting to bind the returned event channel will fail without any indication of a permission error. Signed-off-by: Andrew Cooper Acked-by: Daniel De Graaf --- diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 18a76af8e1..c0fbcea748 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -1148,21 +1148,25 @@ int alloc_unbound_xen_event_channel( spin_lock(&d->event_lock); - if ( (port = get_free_port(d)) < 0 ) + rc = get_free_port(d); + if ( rc < 0 ) goto out; + port = rc; chn = evtchn_from_port(d, port); rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, remote_domid); + if ( rc ) + goto out; chn->state = ECS_UNBOUND; chn->xen_consumer = get_xen_consumer(notification_fn); chn->notify_vcpu_id = local_vcpu->vcpu_id; - chn->u.unbound.remote_domid = !rc ? remote_domid : DOMID_INVALID; + chn->u.unbound.remote_domid = remote_domid; out: spin_unlock(&d->event_lock); - return port; + return rc < 0 ? rc : port; }